[perf] Copy via memoryview in pack_into instead of torch.frombuffer - #154

Problem

pack_into concatenates the msgpack fragments of one object into a contiguous buffer —
a 4-byte header, an 8-byte (offset, length) entry per fragment, then tightly packed
payload. It is a memcpy with an index table.

The old implementation did that memcpy through tensors:

target_tensor = torch.frombuffer(target_mv, dtype=torch.uint8)
for item in items:
    src_tensor = torch.frombuffer(memoryview(item), dtype=torch.uint8)
    target_tensor[payload_offset : payload_offset + nbytes].copy_(src_tensor)

At TQ's object sizes (one key per (sample, field), so a few hundred bytes each) none of
that work is the copy. Timed per step, 1024 objects of 512B, best of 5:

A 512-byte memcpy is tens of nanoseconds. Two tensor objects get constructed and one
dispatcher lookup happens per fragment, and slicing the target costs more than the copy
itself. Tensors are the wrong abstraction here — their fixed per-op cost does not
amortise over a few hundred bytes.

Change

Copy through memoryview slice assignment, which resolves to PyBuffer_ToContiguous ->
memcpy with no object allocation and no dispatcher:

Casting both sides to "B" is required, not cosmetic: slice assignment demands matching
format and itemsize, and callers pass bytes, a memoryview, or a float32 numpy array.
Normalising to unsigned bytes makes the assignment legal and correct for all three.

Second change in the same function: the old code built a memoryview per fragment
twice — once inside calc_packed_size just to read .nbytes, once in the copy loop.
The views are now materialised once and shared, with required computed inline.

Measurements

verl GRPO on main at 750719e, this PR applied alone (the other two perf branches
reverted to baseline). Medians; two independent baseline runs per configuration are
shown to give the run-to-run spread.

Single-node, 512-sample put (1024 objects):

Dual-node, 1024-sample put (2048 objects):

The per-step micro-benchmark ratio (6.70x) and the production ratio (6.1x) agree, so the
mechanism above accounts for the result. Absolute values differ because production
fragments are larger and more numerous than the synthetic 512B case.

yuanrong RPC time is unchanged (32.1 -> 31.5ms single-node, 55.2 -> 61.6ms dual-node),
so the saving is entirely client-side CPU. get_data is unaffected (medians within 3%
across variants).

Note dual-node put_data wall clock is not a reliable metric in this environment: an
intermittent ~480ms run_in_executor handoff delay appears in some runs (two baseline
runs measured 606ms and 1083ms with every instrumented step within 1%, the difference
landing entirely in un-instrumented time). Judge the dual-node effect by TQ-side total
or pack phase, which agree to 0.2%/0.9% between those two runs.

Side effect: GIL contention drops as well

batch_encode_into still dispatches pack_into across 16 threads. Because each task now
holds the GIL for 1.20us instead of 8.07us, the queue stops backing up:

The baseline's per-call wall clock inflates to 1942us under contention; here the
accumulated per-thread time equals the real work, i.e. threads are barely waiting on each
other. That is why the phase improves by more than the 6.7x of the copy alone.

Correctness

Output is byte-for-byte identical to the previous implementation. Both
tests/test_serial_utils_on_cpu.py and tests/test_serial_utils_batch_on_cpu.py pass,
and packed buffers still round-trip through unpack_from/decode unchanged. The
buffer-too-small `ValueError